1. Field of the Invention
This invention generally relates to date-year conversions in computer software programs, and in particular, to date-year conversions in object-oriented software programs utilizing classes which limit the time that computer applications may be utilized.
2. Background of the Invention
The Y2K (i.e., the year 2000) bug has had a profound impact on everyday life of almost each individual. Computer systems used in various processing applications, such as, for example, processing insurance, account, inventory, investment, and retirement information, as well as many other applications, often operate with records and data containing date-dependent information. In many computing systems, date information relating to years has typically been represented in two-digit year formats, where two digits represent a year between 1900 and 1999. Thus, for example, the two digits xe2x80x9c97xe2x80x9d would represent the year 1997. Popular usage of this simplified date information format throughout the computer industry has resulted in an industry-recognized problem, often referred to as xe2x80x9cthe year 2000 problem.xe2x80x9d
More specifically, as a result of this simplification of date information, upon the turn of the century (i.e., upon the year 2000), two-digit year information intended to represent a year within the 21st century will, instead, be indistinguishable by computer systems from a year within the 20th century (i.e., between 1900 and 1999). Thus, for example, a two-digit year value of xe2x80x9c08xe2x80x9d which is intended to represent the year 2008 will be indistinguishable from the year 1908 by such computer systems.
In preparing for the turn ofthe century, substantial time and resources have been invested to insure that computer systems will continue to operate past the year 2000. Based on their experience with the Y2K problem, the public, the government, businesses, financial institutions, and computer companies are keenly aware of the costly effects of correcting date and year restrictions within computer systems.
Additionally, Microsoft Foundation Class (MFC), a popular object-oriented toolkit for developing Windows-based C++ applications, has a well-known date conversion problem, even with the recent focus on date-year restrictions in software programs. The date conversion problem arises because MFC-based applications are capable of representing dates only from 1970 to 2038. While this date problem may not be as critical as the Y2K problem, it is severe enough to jeopardize the normal execution of a business application. The implication of this problem is significant for mission critical MFC-based business software, and if this problem is not addressed properly, the xe2x80x9cYear 2038xe2x80x9d bug will surface for MFC-based C++ applications.
In object-oriented software programs, the term xe2x80x9cobject-orientedxe2x80x9d refers to a software design method which uses xe2x80x9cclassesxe2x80x9d and xe2x80x9cobjectsxe2x80x9d to model abstract or real objects. An xe2x80x9cobjectxe2x80x9d is the main building block of object-oriented programming, and is a programming unit which has both data and functionality (i.e., xe2x80x9cmethodsxe2x80x9d). A xe2x80x9cclassxe2x80x9d defines the implementation of a particular kind of object, the variables and methods it uses, and the parent class to which it belongs.
The problem in MFC-based C++ applications is related to the CTime class. CTime is defined in terms of a variable called xe2x80x9ctime_txe2x80x9d. The variable time_t is a variation of the original UNIX time variable which is defined according to American National Standards Institute (ANSI) standards. The first version of UNIX was developed in 1969 and became effective in 1970. The UNIX time variable, like time_t, counts the number of seconds that have elapsed since Jan. 1, 1970.
The variable time_t is a 32-bit signed long integer representing 2,147,483,647 positive time values and measuring the number of seconds that have elapsed since Jan. 1, 1970. Since there are 86,400 seconds in a day (approximately 31,557,600 seconds in a year based on 365.25 days in a year), the maximum time value that may be represented after Jan. 1, 1970 is approximately 68 years. Thus, time_t is only capable of representing dates from 1970+68 years, i.e., from years 1970 to 2038. More specifically, time_t can calculate time from Jan. 1, 1970, 24:00 hours to Jan. 18, 2038, 19:14:07 hours. After Jan. 18, 2038, 19:14:07 hours, time_t rolls over to a negative number and no longer counts the number of seconds that have elapsed since Jan. 1, 1970.
Consequently, any application program utilizing software based on time_t, including software based on the CTime class of MFC, can not maintain accurate dates and times before Jan. 1, 1970 or after Jan. 18, 2038. This bug exists in each and every object-oriented application utilizing CTimexe2x80x94the problem does not depend on which type of program is utilized or which company developed the program. A number of solutions to solve this problem have been proposed. However, all of these potential solutions have significant shortcomings.
One potential solution is to rewrite the CTime class to accommodate dates before 1970 and after 2038. This approach, however, would require investment of substantial time and money to modify the class and related programs. Furthermore, any modifications to CTime may introduce potential defects into the program. Thus, this solution does not adequately address the problem based on the required time and money required to implement the modifications and resulting defects.
A second potential solution to the year 2038 problem is to rewrite application programs to represent dates beyond the year 2038. This solution, however, is not practical since it requires computer code modifications to not only the application programs, but also to date dependent data files generated by these programs. Modifying data files is likely to be even more costly than modifying application programs simply based on the large number of data files. Thus, this approach does not adequately address the problem.
Third, it has been proposed that the system clock be reset when the year 2038 arrives. This solution, however, is not practical since making changes to the system clock would necessarily result in changes to date dependent data fields. Further, files that were created on two different dates would be assigned the same date. Thus, even if the clock is reset, users would still need to reformat date-year dependent data files.
A final approach to solving the year 2038 problem is to use different time classes within MFC. Utilizing other MFC time classes, however, does not adequately address this problem. One problem associated with other MFC time classes is that all of the years from year 1 to 9999 can not be represented. Rather, other MFC time classes can only represent years 100 to 9999. A second problem with these alternate MFC classes is that they are not as accurate as CTime. CTime can represent time and dates very accuratelyxe2x80x94in increments of hours, minutes, and seconds. Other MFC time classes, however, are only capable of representing time increments in days. A third shortcoming of other MFC time classes is that users are subjected to unnecessary inconvenience. Implementing other time classes in application programs currently utilizing CTime requires users to modify their application program to terminate CTime and to initiate the other time class. These modifications are necessary because other MFC date-related classes do not derive from the CTime class and do not have a CTime constructor. A final problem with other MFC date related classes is that once a user converts to an alternate MFC time class, the user is essentially prevented from converting back to CTime. Users can convert back to CTime if the desired year falls within the range of 1970-2038. However, converting back to CTime within this time period is not particularly useful since CTime and the other date-related classes operate within this time frame. Thus, the user is essentially prevented from converting back to CTime for the problem years outside the range of 1970-2038. Based on these shortcomings, other MFC time classes do not adequately address the 2038 bug based on the required modifications and user inconvenience.
Accordingly, there is a need in the art for a program that converts date-year data in object-oriented software programs created with the CTime class of MFC to insure that systems based on CTime will operate well past the year 2038. This program should convert dates without inconveniencing system users while providing detailed time, date and year information spanning all of the years from 1 to 9999. Further, this program should convert dates without modifying application programs, related data, and system clocks.
To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method, apparatus, and article of manufacture for solving date-year restrictions in object-oriented software programs.
In accordance with the present invention, a technique for converting dates in object-oriented software programs is provided. Initially, a conversion class encapsulates a time class that covers a limited time period. A conversion object is then generated from the conversion class, and when the conversion object is invoked, a target year in which an application program should execute is identified. If that target year is outside of a limited time period, the target year is converted to one that falls within the limited time period.